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Subjects More on Protection Auditing 


ihe aesign review of MIB-103 ("The Protection Audit Mecnanisms 
for Multics") raised several issues that requirea further study. 
Most of the concerns expressed dealt with the performance impact 
of protection auditing, particularly in installations not using 
auditing and/or the access isolation mechanisms. Tnis memo gives 
further details concerning the expecteaq performance cost of 
auditing, ana re-visits several other design issues. 


Locations, 3ize, and Execution Cost of Auditing Calls 


Potentially augitable directory control events anu faults (those 
wnich require a test to see if auuiting is necessary) occur on 
tne order of 5 times a second. lhus, is it important to minimize 
the number, code size, and execution cost of conditional 
sequences and calls for auditing in these areas. the following 
performance-sensitive modules will contain auditing calls in the 
initial implementation. 


aQir_control_error - All directory control programs (should) call 
here wnen a_= process has insufficient access to complete some 
operation. A 3-instruction conditional and a IlI4-instruction 
audit call will be inserted just before the return, to audit 
instances of denied access. 


fim — Some slight restructuring and a conditional audit call are 
necessary to audit illegal procedure faults (not including 
legal EIS instructions or out-of-bounds) and access violation 
faults (not) including ring alarms, out-of-bounds, or illegal 
ring order). Audit checking and calling sequence acds about 3u 
instructions to fim. 


Current plans for a second-stage implementation will involve 
audit sequences in two aaditional performance-sensitive moaules. 


makeknown - wnen the proposed KST changes (MIE-104) are 
implementea, access information in the KSI will make it 
posSible to audit successful initiations of protected segments 
ana agirectories (those With access class greater tnan 
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system-low) in makeKnown. At the point where a segment or 
agirectory is actually aqaed to the KST, about 60 instructions 
of auditing coue wiil be inserteg. Tne auditing of successful 
making Known of protected airectories, normal protectea 
segments, and "system" (ring |! multi-class) segments will be 
governed by separate auaqit select flags. tor segments with 
system-low access class, a 3-instruction test will skip the 
auditing coue. 


find. - Wwnen the recursive maxing Known of parent directories 
fails aue to insufficient authorization to search further, it 
is desirable to log the full pathname of the segment. At 
present, find. is not structured well enough to do this 
conveniently. A re-write of fina_ will allow this type of 
augiting, and will probably result in a worthwhile improvement 
in system performance. : 


It is expected that, in a system not performing any auditing, the 
execution cost of the aaditional auditing checks will be arouna 
20 instructions/second, quite negligible. 


Performance Costs of Augiting 


An actual auditing call represents somewhere between 500 ana 1 UUU 
instructions, including tne call to protection_audit_, the calls 
{t makes to acquire all the information neeaed for tne log, the 
call to syserr, and the later invocation of syserr_loager to copy 
tne syserr wirea buffer into a paged buffer. Tnus, in normal 
system operation (i.e., no user purposely generating extra. 
auditable protection events), auditing of all protection events 
for all processes can represent as much as about 5 milliseconds 
overhead per secona of real time. fhis is a significant cost, 
but iS not unreasonable if one bears in mind that only 
installations using auditing will pay this cost. 


Given the cost of .5 - I millisecond per audit log entry, it is 
possible for a user to cause a great deal of system overheaa by 
repeatealy causing auditable protection events. In installations 
wishing to detect "penetration" attempts, this overhead will 
certainly be justified. Future enhancements of protection 
auaiting will probably incluae detection of significantly 
abnormal auditing frequency, probably with an 
exponentially-weighted per-process auditing frequency meter in 
the pds. 


Message Segment Auditing 
The new message segment desim (see MIB-10O1) marks message 


segments as "“multi-class" because they may contain messages of 
many access classes, ana assigns the message segment itself a 
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class equal to the highest class of message it can contain. 
because message segments are manipulated only by ring i 
primitives, and because the actual protected objects are tne 
inaividual messages themselves, initiations of message segments 
are not very interesting security events. fhe eventuai needa is 
for some finer-grained auditing of the use of message segments. 
lo prevent flooaging of the syserr audit log with innocuous 
messages for dprint and absentee request submissions, a separate 
pds audit select flag will control the auditing of ring | 
multiple class segment initiations. makeknown will check for 
tnis case when determining whether to audit the initiation of a 
protected segment. This allows initiations of normal protected 
segments to be audited without requiring "system segment" 
initiations to be audited. 


Audit 2electivity Classes 


Mainly for performance reasons, the auait selectivity classes 
defined in MIBb-103 have been recefined. There are two groups of 
flags (in the left and right 1& bits of a word in the pus), one 
group for events audited directly in ring O, and one group for 
events audited via a gate from ring lI. 


~ initiations of protected non-airectory segments (tnose . witn 
access class greater than system-low), not incluging ring | 
multi-class segments 


- maxing known of protected directories (These are separatea 
Out because many directories may be maqae known = as 
by~proaucts of other operations. Knowledge of the making 
xnown of a protected directory is generally of less 
importance than the initiation of a protecteq non-directory 
segment. ) 


~ initiations of ring | multi-class segments 


- access deniea to any segment or directory aue to improper 
authorization, ACL mode, or ring validation level 


- ring-related access violation faults (except ring alarms ana 
illegal ring orders) 


- ACL mode related access violation faults (except 
out-of-—bounas ) 


- illegal proceaure faults (except legal elS faults and 
out-of-—bounds) 
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attempted IPC sena-downs 


~- assignment of system privileges to a process (eitner blanket 
privileges, or privileged initiation of single segments) 


- rejecteu device attachments (tape ana aisk arives) 


~ protection relatea actions of the SSA (performea by ring U 
primitives) sucn as segment downgrading ana turning off 
securitly-out-of-service 


ring | auwit selectivity classes: 
- rejectea media (tape ana aisk) mounts 


- message segment protection events (such as overflows) 


Per- segment Audit selectivity 


being able to audit the uSe ana attempted misuse of specific 
Segments for all processes allows the use of selected protected 
information to be monitorea without requiring the auditing of all 
use and attemotea misuse of all protected information for all 
processes. | 


ine initial design of this capability used a bit in the brancn to 
cause auuiting on all initiations, access uenials, ano access 
violation and illegal procedure faults. Tne cost of cneckine a 
bit in the brancn durina fault processing is far too nign for tne 
marjinal value of aucaiting such faultS, So no per-segment 
augiting will be done on faults. 


AS per-sejment auuit flags will change infrequently, ana since 
such cnanges will not need to become effective immeciately, tnis 
flag can ne copiec into the KS! entry when tne segment iS maue 
known, to save airectory locking. 


AS per-segment audit selectivity is not an immeagiate necessity, 
tne only change will be to reserve a bit in tne branch ana a bit 
in the KSl. 


Metering 2lans 


lo provite concrete aata on cuestions of protection auditing 
performance, some meters will be addec: 


faults - No one seems to have any good idea of the frequencies of 
Various Kinas of faults. A simple aos instruction in fim will 
provide a histogram of faults that reacn fim. ihe nistogram will 
go into the unusea space in wirea_haracore_cGata. inese meters 
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may not be permanent. 


augiting checks ~ some temporary meters will be useful to 
agetermine how often audit cnecks are made. At each place wnere 
an audit select flag is checked in ring 0, a counter in 
active_nardcore_aata will be updated. Since tnese meters will 
definitely reference an additional page each time an aucit flag 
is checked, tney will not be permanent. 


aygiting time and paging - Some permanent meters maintained by 


protection_audit_ will recora in active_haracore_data the average 
time and page faults spent logging audit messages. 
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